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0. Le XfJ.P initialise f<-l 

1. Le X|aP deztiande au XT 1' ectoinstruction num6ro 1 

2. lie XT envoi au INSi au Xm,P 

3. Le X^tP execute INSi 

4. Aller ^ l^^tape 1. 
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0... X|jP INITIALIZES f-1 

1 ... XUP REQUESTS ECTOINSTRUCTION NUMBER / FROM XT 

2 ... XT saiDS msf to xmp 

3 ... XpP EXECUTES INS/ 

4 ... CO BACK TO STEP 1 



(57) Abstract: The invention concerns a method for dynamically authenticating an executable programme, that is the continuation 
of the instructions defined thereby. More specifically, the authentication of a programme is performed repeatedly during the very 
execution of said programme. The method for making secure an electronic portable object through execution of a programme P 
supplied by another insecure electronic object uses, inter alia, a secret key protocol. 



(57) Abrege : La pr^sente invention ddcril un proc^d6 permettant d'authentifier dynamiquemenl le contenu d'un programme ex6- 
^\ cutable, c'est-^-dire la suite des instructions que celui-ci d^finit. Plus pr6cis6ment, I'authentification d'un programme est r6alis6e 
de mani^re r6p6t6e au cours de Tex^cution mSme dudil programme. Le proc6d6 de s^curisation d'un objet portable 6Iectronique 
executant un programme P fourni par un autre objet 61ectronique non sOr, utilise, entre autre, un protocole ^ cl^ secrete. 
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PROCEDE AUTHENTIFICATION DYNAMIQUE DE PROGRAMMES 

PAR UN OB JET PORTABLE ELECTRONIQUE ' 



Ce brevet invention d6crit un proc6d6 permettant 
d^ authentif ier dynamiquement le contenu d'un programme 
executable r est-^-dire la suite des instructions que 
celui-ci d6finit. Plus pr6cis6ment, 1' authentif ication d'un 
5 programme est r6alis6e de mani^re r6p6t6e au cours de 
1' execution m§me dudit programme - 

Le principe de f onctionnement de 1' invention permet 
de concevoir un nouveau type d'616ment s6curis6 appel6 
« Externalized Microprocessor » oix X|XP qui^ contrairement cL 

10 d'autres dispositifs de calcul tels que la carte ^ puce 
(objet de nombreux brevets corame par exemple FR-2 266 222) 
ne contient pas de mfemoire programme (classiquement appel6e 
m6moire ROM, de 1' anglais « Read Only Memory ») . A la 
difference des dispositifs classiques, en effet, le X|LlP 

15 peut ex6cuter des programmes qui lui sont transmis au 
moment mSme de leur exfecution, en toute s§curit6. 

Les avantages qu'un dispositif mobile de calcul sans 
mfemoire ROM pr6sente par rapport aux technologies de calcul 
embarqu6 classiques (nous prendrons la carte A puce corame 

20 technologie de r6f6rence) sont extremes : 

le masquage, operation industrielle au cours de 
laquelle on grave une m6moire ROM sp6cifique, 
dispar al t tot alement ; 

25 

la correction des bogues se resume ^ une mise ^ 
jour des programmes stock6s dans le disque dur des 
terminaux ou sur un r6seau de communication tel 
qu' Internet, et ne nfecessite done pas de devoir 
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retirer du inarch6 ou renouveler des cartes k puce 
defectueuses ; 

plus important encore, la taille des programmes 
n'est plus un facteur limitant. 

5 

Ce dernier avantage est d'autant plus attractif que la 
tendance technologique a tou jours 6te de falre ex6cuter i 
la carte d puce des programmes de plus en plus complexes et 
done de plus en plus voliomineux. D^un point de vue 

10 Indus triel et fonctionnel, une carte k puce est un 
ordinateur miniature. Une petite m6moire volatile RAM (de 
1' anglais « Random Access Memory ») embarqpi6e avec le 
microprocesseur sert k stocker les r6sultats temporaires 
d' un calcul et le microprocesseur de la puce execute un 

15 programme 6crit de manidre non modifiable dans la m6moire 
ROM : l^homme de rattier emploie le terme de gravure, cette 
gravure ayant et6 effectuee k l'6tape dite de masquage. Ce 
programme ne peut ensuite plus §tre modifi6 de quelque 
f agon . 

20 Pour le stockage de donn6es sp6cifiques k 

1 'utilisateur,. les puces contiennent une m6moire non 
volatile EEPROM (pour « Electrically Erasable and 
Programmable ROM ») ou Flash, ces deux types de m6moires 
pouvant autoriser k la fois lectures et 6critures par 

25 centaines de milliers. Les cartes Java, cartes ^ puce 
particuli6res, permettent m§me 1 ' importation de programmes 
executables (appel6s « applets », acronyme de 1' anglais) 
dans leur m§moire non volatile selon les besoins du 
d6tenteur de la carte. En outre, les cartes Java de 

30 derniere g6n6ration embarquent un 6diteur de lien 
(« linker ») , un module de chargement (« loader ») , une 
machine virtuelle Java, des modules d' appels de m6thode k 
distance (« remote method invocation module» en anglais) , 
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un v6rificateur d' applet (« bytecode verifier») ^ un pare- 
feu pour applications Java r6sidentes (« applet 
firewall ») f un ranaasse-miettes (« garbage collector ») , 
des librairies cryptographiqueSf des gestionnaires 
5 complexes de pile, etc. 

Finalement, une carte 4 puce comprend un port de 
communication pour I'echange de donnees et d' information de 
contr61e avec le monde externe. Un taux de communication 
classique est de 9^600 bits par seconde, mais des taux 

10 beaucQup plus rapides compatibles avec la norme d6finie par 
I'ISO (« International Organization for Standardization ») 
sont g6n6ralement employes (de 19^200 jusqu'^ 115/200 bits 
par seconde) . L' apparition du protocole USB dans le monde 
de la carte ^ puce ouvre de nouveaux horizons et permet 

15 facilement d'' atteindre des debits de I'ordre du megabit par 
seconde- Dans ce contexte, il devient tentant d'^extraire la 
raemoire ROM du module de f onctionnement de la carte ^ puce, 
et de s'appuyer sur un protocole de communication ultra- 
rapide pour transmettre lorsque n6cessaire les programmes 

20 qu'elle contenait auparavant- 

D'un autre c6t6/ faire ex6cuter par un dispositif 
mobile un programme executable transmis par un terminal 
potentiellement non-sfir et raalveillant pose d' importants 
probldmes de s6curit6. Le probl^me essen^tiel d'une telle 

25 approche reside dans la pr6sence de cl6s cryptographiques 
stockees dans la memoire du dispositif lui-m§me. Un 
programme malveillant (distinct par voie de consequence des 
programmes s^ executant 16gitimement sur le dispositif) 
pourrait en effet tenter de reveler ou modifier la valeur 

30 desdites cl6s/ invalidant ainsi totalement la s6curit6 des 
applications les utilisant pour fonctionner. 

L' invention que nous allons d6crire permet de r^pondre 
tr^s efficacement ^ cette probl6matique avec I'aide de 
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fonctions de cryptographie syin6trique (dite aussi 
cryptographie k cl6 secrete) classiques et efficaces : une 
fonction de MAC (selon I'acronyrae anglais « Message 
Authentif ication code ») et quelques fonctions de hachage, 
5 traduction du terme anglais « hashing » provenant du verbe 
« to hash ». 

Ces fonctions de hachage seront notfees HASHi^ HASH2 et 
HASH3 dans le brevet. Conf orm^ment k l'6tat de I'art^ ces 
fonctions sont d6finies par une fonction dite de 
10 compression. Par dfefinition, on dit que HASH est une 
fonction de hachage d6finie par une fonction de compression 
H et par une constante IV (de 1' anglais « initialization 
vector ») ^ lorsque la definition suivante s' applique: 
HASH(ai,a2f ...f ak)= H (HASH (ai, ...^ ajt-i) f ak) 
15 avec le cas particulier suivant : 

HASH(ai)= H(IV^ai) 
les norabres entiers ai^ 3.2 f —f dfesignant ici les 

arguments de la fonction de hachage. 

Dans ce document, nous utilisons done les fonctions de 
20 hachage HASHi, HASH2 et HASH3 qui sont respect ivement 
d6finies par (Hi^IVi), (Ha^IVa) et (H3rIV3). 

Ainsi, le r6sultat d'un hachage se calcule 
it6rativement k I'aide d'une boucle et plusieurs appels k 
la fonction de compression determinant le hachage. De 
25 telles fonctions de hachage sont tr^s classiques en 
cryptographie: citons par exemple les fonctions de hachage 
SHA et MD5 dont les specifications reposent sur la 
description donnee ci-dessus. 

La presente invention sera plus facilement comprise A 
30 I'aide des figures jointes. 

La Figure 1 d6crit la semantique dynamique d'^un 
exemple de jeu d^ instructions appel6 XJVML permettant 
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d'illustrer de fa^on non limitative les diff6rents modes de 
realisation de 1'' invention. 

La Figure 2 d6crit le procedfe naif de l'6tat de I'art 
permettantr de fagion non sflre, d'ex6cuter un programme P 

5 fournit par le monde ext6rieur au X(XP. 

La Figure 3 d6crit une politique de s6curlt6 en XJVML 
selon 1' invention, autorisant la lecture et I'ecriture de 
donnfees dites publiques. 

La Figure 4 d6crit une politicjue de s6curit6 en XJVML 
10 selon 1' invention, autorisant uniquement la lecture de 
donn6es dites publiques. 

La Figure 5 explique la gestion de la politicjue de 
s6curit6 au cours de 1' execution du programme P. 

Dans la suite du texte, nous verrons un programme 
15 donn6 P d6fini sur un jeu d' instruction (ou langage de 

r 

programmation) comme une suite ordonn6e d* instructions : 

1 : INSi 

2 : INS2 

3 ••« 

20 F : INSf, 

ces instructions 6tant positionn6es k des adresses 
appartenant k 1' ensemble {1,...,F}, F d6signant le nombre 
d' instructions du programme P. 
25 Nous ddfinissons §galement, i. titre d'exemple 

illustratif non limitatif, un jeu d' instruction appel6 
XJVML qui servira cL illustrer les modes de realisation de 
1' invention. 

XJVML d6crit une architecture simpliste bas6e sur le 
30 processeur virtuel JVMLO d6fini dans le document de R- 
Stata et M. Abadi intitul6 en langue anglaise « A type 
System for java Bytecode Subroutines » publi6 dans le 
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document reference SRC Research Report 158 le 11/06/1998 
disponible d I'adresse electronique suivante : 
http ; / /www . research , digital , com/ SRC/ ■ 
architecture sur laquelle op6re XJVML est semblable 
au module de calcul connu de I'horame de I'art conrnie etant 
celui de von Neumann^ a ceci pr6s qu'elle ne contient pas 
de iii6moire programme. L' architecture de XJVML comporte : 

- une memoire volatile appelfee RAM, 
une m6moire non volatile appel6e NVM, 

un generateur de nombre al6atoire appel6 RNG, 
une pile d'operande appel6e ST, 

- un port de communication (dit aussi d'entr6e/ 
sortie) appele 10. 

Le jeu d' instructions de XJVML est d6fini par les 
instructions suivantes, oii x denote une donn6e immediate, L 

est I'adresse d'une instruction avec 1 ^ L :^ F et F est le 
nombre d' instruction du programme consid6r§ : 

• L' instruction ^inc' incr6mente la donnee se 
trouvant sur le soramet de la pile. L' instruction 
^pop' retire l'616ment de pile se trouvant a son 
sommet : on utilisera le vocable « d6piler ». 
L' instruction "*pushO' ajoute la donn6e constante 
0 au-dessus de 1^616ment se trouvant au sommet 
de la pile : on utilisera le vocable 
« empiler »• 

• L^ instruction "^load x' empile la donn6e se 
trouvant a I'adresse x en RAM. L' instruction 
^ store x' depile la donnee au sommet de la pile 
et la recopie d I'^adresse x en RAM. 
L' instruction ^load 10' capture la donn6e 
presentee sur le port de communication et 
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l^empile tandis que 1' instruction ^store 10' 
depile la donn6e sup6rieure de la pile et la 
recopie sur le port 10. L' instruction ^load RNG' 
produit un nombre aleatoire et I'empile. 
5 instruction ''store RNG' n'existe pas. 

• instruction ^if L' observe la donn6e au soiranet 
de la pile et initialise le compteur de 
programme a L si cette donn6e n'est pas nulle. 

• L' instruction ^halt' arrSte 1' execution du 
10 programme . 

• L' instruction ^getstatic x' empile la donn6e 
stockfee en NVM i I'adresse x et 1' instruction 
^putstatic x'' d6pile la donn6e superieure de la 
pile et la stocke dans la m6moire non volatile cL 

15 I'^adresse x. 

• L' instruction ^xor' d6pile les deux donn§es 
sup6rieures de la pile^ calcule le XOR (OU 
EXCLUSIF) de ces donn6es et empile le r6sultat. 
L'effet de 1^ instruction Mec' est 1' exact 

20 oppos6 de celui de 1' instruction ^inc'/ c'est ^ 

dire que la donn6e sup6rieure est d6cr6mentee de 
1. L*^ instruction ^mul' d6pile les deux donn6es 
sup6rieures, les multiplie et empile les deux 
donn6e5 repr6sentant le r6sultat sous forme de 

25 deux mots^ I'un de poids fort^ 1' autre de poids 

faible. L' instruction ^goto L' est un simple 
saut d I'adresse de programme L- Enfin^ 
1' instruction ^div' d6pile les deux donnees 
sup6rieureSf divise la moins haute de ces deux 

30 donn6es (le numerateur) par la donn6e la plus 

haute dans la pile (le ddnominateur) , et empile 
la donn6e resultant de 1' Evaluation du quotient. 
II est a noter que si, pour 1' instruction Miv' , 
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le d6nominateur est nul, une exception est 
ex§cutee, et le compteur de programme est 
reinitialise ^ l^adresse du d6but de 
1' exception, adresse appel6e AdExcDiv par la 
5 suite. Cette exception est appel6e 1^ exception 

« division par z6ro ». 

La s6mantique dynamique de notre jeu d' instructions 
est sch6matis§e ^ la Figure 1 noter qu'il n'y a aucune 

10 r^gle pour 1' instruction ^halt' . Dans la Figure 1, « undef» 
d^signe la donn6e par d6faut d'une cellule de la in6moire. 

II est implicite que les instructions qui utilisent 
la pile provoquent une interruption si la pile est vide, 
c'est ^ dire, en d6notant par s le nombre d^616ments de la 

15 pile, si s = 0, ou bien si elle contient insuf f isamment de 
donnfees, par exemple lors de 1' execution d'une instruction 
'^xor' alors que s = 1- 

On rappelle cjue le terme X|XP d6signe le dispositif 
soumis au proc6d6 de 1' invention, c'^est ^ dire un 
20 dispositif 61ectronique d6pourvu de m6moire progrcunme, et 
que similairement, le terme XT dSsigne l'« Externalized 
Terminal », c'est a dire le terminal qui communique avec le 

X\iP et contient le progrcunme P que celui-ci ex6cute. 

On rappelle aussi que le programme P introduit dans 
25 chaque terminal XT (que I'on rappelle etre non stir et 
possiblement malveillant) se pr6sente sous la forme d'une 
suite d' instructions : 

1 : INSi 

30 2 : INS2 

3 

F : INSf 
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Le principe de l'6change entre le X^lP et le XT est 

trSs simple: lorsque l*ex6cution commence, le X|uiP 
initialise ^ 1 son compteur de programme, r§f6renc6 ci- 
dessous par la variable i, et demande 1 ' instruction 

5 d'adresse i au XT. Le X|LiP execute INSi, mettant ainsi §. 
jour son 6tat interne et determinant par consequent la 
nouvelle valeur du compteur de programme. Le compteur de 
programme i et I'adresse de INSi se confondent lors de 
1' execution du programme. Ainsi, lors de 1' execution du 
10 programme, i designera de fagon 6gale I'adresse comme le 
compteur de programme- Ce proc6d6 est r6p6t6 tant 
qpie 1' instruction de fin de programme n'est pas atteinte. 

A titre d' illustration, le protocole naif (simple et 

non sur) d'6chajige entre le XT et le X|LiP s'6crit comme 
15 mentionn6 en Figure 2 (en se rappelant qu'ex6cuter INSi met 
^ jour i) . 

Ainsi qu'il apparalt clairement, ce proc6de simple 
est sujet ^ de nombreuses attaq[ues- Typiquement, un 
attaquant peut retrouver la valeur d^une cl6 secrdte 

20 stoGk6e dans la m6moire du XjXP, avec I'aide du programme 
XJVML suivant: 



1 


getstatic 


1 


2 


store 10 




3 


getstatic 


2 


4 


store 10 




5 


getstatic 


3 


6 


store 10 





30 
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Un attaquant pourrait 6galement, par exemple^ 
modifier le montant d'un porte-monnaie 61ectronique en sa 
f aveur - 

Nous proposons done plusieurs modes de r6alisation de 

5 I'authentification du programme P qui est transmis au X|XP. 

De manidre g^n^rale, 1' invention concerne un proc6d6 

de s6curisation d'^un objet portable 61ectronic[ue XpP 

executant un programme P fourni par un autre objet 
61ectroniq[ue non stir XT, caract6ris6 en ce q[u' il utilise ; 

10 - un protocole ^ cl6 secrete; 

- une cl6 secrete 6phemdre K; 

- une fonction de MAC |Xk; 

- une fonction de hachage HASHi d6finie par une 
fonction de compression Hi et une constante IVi; 

15 - une fonction de hachage HASHa d6finie par une 

fonction de compression H2 et une constante 

- un identifiant de programme ID stocks dans 1' objet 

61ectronique XpP et valant un hachage de P. 

Dans une premiere partie de 1' invention, ce proc6d6 
20 de s6curisation d'un objet portable 61ectronique est 
caract6ris6 en ce cjue le programme P est fourni sous la 
forme d'une suite de F instructions, F d^notant ainsi le 
nombre d'' instructions de ce programme P. 

Dans cette premiere partie de 1' invention, la valeur 
25 de ID, c[ui correspond au hachage du programme P, se calcule 
en hachant, une ^ une, les instructions, dans I'ordre 
croissant des adresses. 

De fagon plus precise, la premiere partie de 
30 1' invention est caracteris6e en ce que ledit protocole 
comporte les phases suivantes : 
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a) une phase d' initialisation durant laquelle le 
XpP g^ndre une cle 6ph6in6re K, puis regoit du XT 
1' ensemble du programme Pr le nombre d' instructions F et 
son identifiant ID, calcule le hach6 h de ce programme P 

5 avec la fonction HASHi, en utilisant la fonction de 
compression Hi et la constante IVi, et enfin g6n6re des 

signatures 0, k I'aide de la fonction [lLk et de la cl6 

signatures qu'il transmet au XT; 

b) une phase d' execution durant laquelle le XpP 

10 verifie l'egalit6 entre les valeurs de h et de ID, v6rifie 
6galement que ID est stocks dans sa m6moire non volatile, 
puis demande, I'une aprds 1' autre, les instructions de P 
pour les ex6cuter, et pour certaines d' entre elles, 
effectue une sous-phase de verification qui consiste ^ 

15 demander une signature o, construite a partir des 

signatures g6n6r6es lors de la phase d'' initialisation et 

k I'aide de la fonction HASH2, et ^ verifier cette 

signature o; 

c) une phase de reaction qui se d6roule dds qu^une 

20 signature a est non valable, et qui consiste pour le XjiP k 

prendre les mesures n6cessaires centre le XT frauduleux. 

Cette premiere partie de 1' invention se decline alors 
en plusieurs modes, appeles premier, deuxi^me et troisieme 
modes de realisation de 1' invention. 
25 Dans le premier mode de realisation, le proc6d6 de 

s6curisation d'un objet portable §lectroniq[ue est 
caract6ris6 en ce que la sous-phase de verification dans la 

phase d' execution est une verification de la signature a se 
d6roulant avant 1' execution de chaque instruction. 

30 
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De fa^on plus precise/ ce premier mode de 
realisation est caract6rise en ce cjue la phase d' execution 
comporte les sous-phases suivantes : 

b-1) le X|iP demande une instruction au XT; 

b-2) le XpP demande une signature a construite cL 

partir des signatures a, gen6r6es lors de la phase 
d' initialisation et ^ I'aide de la fonction HASH2/ 
et^ en cas de non-validit6 de cette signature Of 
execute la phase de rfeaction; 

b-3) le XjiP execute 1' instruction et retourne k la 
sous-phase b-1 . 

Ainsi^ de fagon pr6f 6rentielle^ le premier mode de 
s6curisation d'un objet portable ^lectronicgpae selon 
1' invention est caract6ris6 en ce qu' il utilise un 
protocole ^ cle secrete comprenant les 6tapes suivantes : 

-2. Le X|XP g6n6re une cl6 al6atoire de session K, demande au 
XT 1' identifiant ID du programme, le nombre d' instructions 
F qu'il contient et initialise h^IV[ 

-1. Pour i-t-1 ^ F 

(a) Le X|XP demande au XT 1' instruction num6ro i 

(b) Le XT envoie 1' instruction INS, au X|xP 

(c) Le XfiP calcule la signature a,. <— JAj^ (ID,/,INSJ et 
met k jour h<r- H^ih^INSg) 

(d) Le X^lP envoie au XT (aucune copie de n'est 
gard6e dans le XfiP ) 

(e) Le XT enregistre 

0. Le X(XP v6rifie que A = ID , que ID est present en ra6moire 
non volatile (en cas d'6chec aller ^ l'6tape 7) et 
initialise / <— 1 

1. Le X|lP initialise V <— JT^ 
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2. Le XT initialise 0 <— /Fj 

3. Le XfiP demande au XT 1' instruction num^ro i 

4. Le XT 

(a) met ^ jour O ^ H2(p,0^) 

(b) envoie INS^ au X|XP 

5. Le XjxP met ii jour V <- iaT^ (V , |LL^ (/Z), /, /AW J) 

6. Le X|LlP 

(a) demande O au XT et v^rifie que G -V ; en cas 
d'^chec, aller ^ l'6tape 7 

(b) execute INS^ 

(c) retourne ^ 1' 6 tape 1 

7. Le X|XP sait que le programme fourni est un programme non 
authentique, et prend done toutes les mesures n^cessaires 
defensives de protection. 

Dans le pr6c6dent paragraphe, IVi et IV2 d6signent 
les vecteurs initiaux des fonctlons de hachage HASHi et 
HASH2; 1 est toujours la valeur repr6sentant le compteur de 

programme; Gj, d6signe la signature de I'' instruction INSi. 
On rappelle qfue 1' execution de INSi modifie la valeur de i. 
Les lettres h,. V et a d6signent des variables du protocole 
dont 1' utilisation est expliqu6e dans ce qui suit. 

Le protocole ci-dessus comprend diff6rentes 6tapes . 
Nous avons not6 par (-2) et (-1) les 6tapes dites negatives 
qui se d6roulent avant 1' execution du programme P et par 
(0) ^ (7) les 6tapes dites positives qui se d§roulent 
durant 1' execution du programme P. 

En 6tape (-2), le X|aP g6ndre de fagon al6atoire une 
cl6 K &ph§mere. Cette g6n6ration aleatoire peut se faire 4 
I'aide d'un g6nerateur de nombre al6atoire (« random number 
generator » en anglais) materiel ou k I'aide d'un autre 
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moyen. De plus, la valeur h est initialis6e a la valeur 
initiale IVi . 

L'^tape (-1) est une boucle sur les adresses de 
programme i. Elle est constitute de sous Stapes. 

5 • Dans la sous 6tape (-l.a), le XfXP demande k XT 

1' instruction d'adresse i 

• Dans la sous etape (-l.b), le XT envoie au X|LiP 
1' Instruction demandee 

• Dans la sous etape (-l.c), le X|xP calcule la 
10 signature sym6trique (aussi appel6e signature ou 

MAC) Oi de 1' instruction. De plus, le XjlP 
accumule le hachage du programme dans la valeur 
h au moyen de la fonction de compression Hi. 

• Dans la sous 6tape (-l.d), le MAC Gt est envoy6 
15 par le X^P au XT. 

• Enfin, dans la sous etape (-l.e), le MAC Gx regu 

du Xp.P est stock6 par le XT. 
Se dtroulent par la suite les 6tapes ayant lieu 
pendant 1^ execution du programme P. 

20 A l''6tape (0), le XfXP verifie que la valeur finale de 

h (calcul6e durant la boucle de 1' etape (-1) > est 6gale k 
la valeur ID, stock6e dans sa memoire non volatile. GrS.ce ^ 
la propria t6 de non-collision de la fonction de hachage, le 

XjiP est ainsi stir que le programme pour lequel il a calcul6 

25 la sequence des MACs a± pendant les 6tapes negatives est 
ef f ectivement autorise a 1' execution. De plus, pendant 
I'ttape (0), le compteur de programme i est initialise ^ 1. 
Si la valeur de h diffdre de celle de ID, le programme 
envoy6 n'est pas authentique, et la section (7) est 

30 ex6cut§e : le X^P prend alors les mesures adtquates contre 
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1' agression supposee (par exemple^ le X|LiP efface sa 
m^moxre) . 

Les 6tapes (1), (2), (3), (4)^ (5)^ (6) sont alors 
r6p6t6es un certain nombre de fois^ juscgfu'^ ce que 
1' instruction finale soit ex6cut6e. Ce precede de boucle 
est expliqpife dans ce qui suit. 

En 6tape (1), le X\iF initialise la variable V A IV2. 

En 6tape (2), le XT initialise la variable IV2. 

A l'6tape (3)^ le XjLlP demande au XT 1' instruction 
d''adresse i. 

A l'6tape (4), le XT remet a jour la variable a et 

envoie au X|XP 1' instruction demand^e. 

A l'6tape (5), le X\xB remet d jour la variable v. 
L'6tape (6) est l'6tape critique pour la s6curit6. 
Les sous-6tapes (6.a)f (6.b) et (6.c) sont effectu6es. La 

sous-6tape (6. a) est une sous-6tape durant lac[uelle le XjiP 

demande au XT de lui envoyer la signature collective a. Le 

X|XP fait alors la comparaison avec la valeur v qu'il a 
calculSe auparavant. Si ces valeurs different, le programme 
P regu n'est pas authentique et I'fetape (7) est alors 

ex6cut^e : le X^P prend alors les mesures appropri6es 

centre cette agression. Si ces valeurs sont 6gales, le X|llP 
continue 1' execution du protocole en executant 
1' instruction regue et en retournant cL l'6tape (1). 

Ainsi, dans les 6tapes n6gatives, le X|aP signe lui- 
m&me le programme qui lui est envoy6 avec I'aide d'une cl6 
6ph6m6re tout en v6rifiant que celui ci est correct en 
comparant le hachage du programme qui lui est envoy6 ^ 
1' identif iant qu'il contient dans sa m6moire (ID). Dans les 
6tapes positives^ il ne reste alors plus qpa'^ comparer^ 
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pour chaqn^e instruction^ la signature fournie par le XT ^ 

celle que le X|XP recalcule, 

II est ainsi impossible pour le XT d'envoyer une 
instruction 6trangere: il n'a pu faire signer 4 l'6tape (- 
5 1) un programme autre que celui d' identif iant ID sans etre 
d6tect6 k l'6tape (0)^ du fait de la propri6t6 de non- 
collision de la fonction de hachage. Par suite, durant 
1' execution des 6tapes positives / le XT ne peut qu'envoyer 

des instructions sign6es par le X^P au cours de 1' execution 
10 des 6tapes negatives, c'est k dire les instructions 
correspondant ef f ectivement au programme; dans le cas 
contraire, si le XT essaie d'envoyer des instructions 
diff§rentes, il ne pourra envoyer la signature correcte 
lors de la verification car il ne peut calculer par lui- 
15 m§me les signatures d'autres instructions du fait qu' il ne 
connalt pas la cl6 de signature K. 

Cette solution est sQre, mais peut §tre sujette 4 
ameliorations • 

Le premier mode fait I'objet d'une amelioration qui 
20 est un deuxiSme mode de realisation de verification 

dynamique du programme P qui est envoye au XjiP. Dans ce 
deuxidme mode de realisation, seules certaines instructions 

d6clenchent une verification de la signature collective a. 

Pour cela, nous repertorions dans une liste les 

25 instructions qui emettent vers l^exterieur du X|iLP de 
1' information relative aux donnees utilisees lors de leur 

execution dans le X|lLP (par exemple les instructions du 
commandement du port d' entree-sortie) . Ensuite, on ajoute a 
cette liste d' instructions les instructions qui 
30 susceptibles de modifier l'6tat de la memoire non volatile 
du dispositif . Toutes ces instructions sont appeiees 
critiques pouxr la. sScurite dans les sections suivantes et 
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1' ensemble des instructions critiques pour la security est 
not6 S. 

Reprenant 1*" example illustratif du langage 
616mentaire XJVML, nous r6pertorions ainsi les instructions 
5 qui ont, pour certaines valeurs de leurs entries, un 
comportement special, reconnaissable de I'extferieur. Une 
instruction est alors appel6e ^^tragable" si la valeur des 
donn6es utilis6es par 1' instruction peut influencer la 
valeur d'une variable physiquement observable (par exemple 

10 le compteur de programme) . Les instructions ''if L' et ^div' 
sont done tradables en raison de leur influence sur le 
compteur de programme (1' instruction ''div' pouvant 
provoquer une interruption en cas de nullit6 du 
d6nominateur) . L' inverse de cette notion est celui d' 

15 "indistinguabilit6 en donn6es" qu± caracterise les 
instructions pour lesquelles les donn§es utilis6es n'ont 
aucune influence sur les variables environnementales . Par 
exemple, 1' execution de 1' instruction ^xor' ne r6v^le pas 
d' information sur les deux 616ments du haut de la pile qui 

20 pourrait §tre observ6e de l'ext6rieur du X|lIP. 

Comme 1' execution d' instructions tradables peut 
r6v61er de 1 ' information sur des valeurs internes du 
programme, ces instructions sont par definition critiques 
pour la s6curit6 et nous les incluons done dans S. Par 

25 exemple, dans notre jeu d' instruction illustratif XJVML, 
seules les instructions ''if L' et ^div' sont tragables et 
1' ensemble S est done d6fini comme ci-dessous: 

S = {putstatic X, store 10, if L, div} 

30 

instruction ^ store IC est dans S car elle pourrait 
declencher 1' Emission d'un signal 61ectrique a l'ext6rieur 
(par le port d' entr6e-sortie) . instruction ^putstatic x' 
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est 6galement dans S car elle peut effectuer une 
modification de la m^moire non volatile. 

Ainsi, pour un jeu d'^ instructions donn6, la 
classification des instructions permettant de d6finir S 
5 nous conduit done au deuxi^me mode de r6alisation de 
1' invention tel que d6crit dans la section suivante- 

Dans ce deuxi^me mode de realisation de 1' invention^ 
le proc6d6 de s6curisation d'un objet portable 61ectronique 
est caracteris6 en ce que la sous-phase de verification 
10 dans la phase d' execution est une verification de la 
signature O se d6roulant avant 1' execution de 
1' instruction^ si celle-ci est une instruction critique 
pour la s6curit6. 

De fagon plus precise, dans ce second mode, le 
15 proc6d6 de s6curisation d'un objet portable 61ectronique 
est caract6ris6 en ce que la phase d' execution comporte les 
sous-phases suivantes : 

b"l) le X|iP demande une instruction au XT; 
b-2) si cette instruction est critique pour la 
20 s6curit6/ alors le XpP demande une signature a 

construite cL partir des signatures a, g6n6r6es lors 
de la phase d' initialisation et k I'aide de la 
fonction HASH2r et, en cas de non-validit6 de cette 
signature Or execute la phase de reaction; 
25 b-3) le XpP execute 1' instruction et retourne ^ la 

sous-phase b-1. 

De fagon pr6f ^rentielle, tou jours dans ce second 
mode, le proc6d6 de s§curisation d'un objet portable 
30 eiectronique est caract6ris6 en ce qu'il utilise un 
ensemble d' instructions critiques pour la security S et en 
ce que le protocole comprend les 6tapes suivantes : 
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-2. Le X|lIP g6n6re une cl6 al^atoire de session Kf demande au 
XT I'identifiant ID du programme, le nombre d' instructions 
F qu''il contient et initialise h ^ IV^ 

-1. Pour i^l A F 
5 (a) Le X[iP demande au XT 1'' instruction num6ro i 

(b) Le XT envoie 1' instruction INS, au X|xP 

(c) Le X|iP calcule la signature a, <— JXjg^(lD,/,INS,) et 

met A jour h<r- H^Qi^INS^) 

<d) Le XjiP envoie au XT (aucune copie de n'est 
10 gard^e dans le X)XP ) 

(e) Le XT enregistre 

0 . Le X|XP v6rif ie que h — JDf que ID est present en mSmoire 
non volatile (en cas d'^chec aller k I'^tape 8) et 
initialise / ^ 1 
15 1. Le X|lIP initialise V IV^ 

2. Le XT initialise O ^/Fj 

3. Le X|XP demande au XT 1' instruction num^ro i 

4. Le XT 

(a) met k jour a ^ H^iS^^O ^) 
20 (b) envoie INS, au XlxP 

5. Le X|LlP met k jour V ^ Hj,(y ,\lg^(ID^i,INSJ) 

6. Si mS^eS, le XjiP 

(a) demande C au XT et v6rifie que Cy=V; en cas 
d'Schec, aller k I'^tape 8 

25 (b) execute INS, 

(c) retourne ^ I'^tape 1 

7. Sinon, le X(lP 

(a) execute INS, 

(b) retourne ^ l'6tape 3 



30 8 



Le XjlP salt que le programme fourni est un programme non 
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authentique, et prend done toutes les mesures n6cessaires 
defensives de protection 

Dans le pr6c6dent paragraphe, IVi et IV2 ci6signent 
5 les vecteurs initiaux des fonctions de hachage HASHi et 
HASH2; i denote tou jours la valeur repr6sentant le compteur 

de programme; Oj. d6signe la signature de 1' instruction 
INSt- On rappelle que 1' execution de INSi modifie la valeur 

de !• Les lettres h, v et o designent des variables du 
10 protocole dont 1^ utilisation est expliqu6e dans ce qui 
suit. 

Le protocole se compose de dif f 6rentes 6tapes . Nous 
avons not6 par (-2) et (-1) les 6tapes dites negatives qui 
se d6roulent avant 1' execution du programme P et par (0) k 
15 (8) les 6tapes dites positives qui se d6roulent durant 
1' execution du programme P. 

En etape (-2)^ le X|LlP gen^re de fagon al6atoire une 
cle K 6ph6m6re. Cette generation al6atoire peut se faire k 
I'aide d^'un generateur de nombre aleatoire (« random number 
20 generator » en anglais) materiel ou 4 I'aide d'un autre 
moyen. De plus^ la valeur h est initialis6e k la valeur 
initiale IV. 

L^6tape (-1) est une boucle sur les adresses de 
programme i. Elle est constitute de sous Stapes. 

25 • Dans la sous 6tape (-l.a), le XjiP demande k XT 

1' instruction d'adresse i 

• Dans la sous 6tape (-l.b), le XT envoie au X|XP 
1' instruction demand6e 

• Dans la sous etape (-l.c), le XjlP calcule la 
30 signature symetrique (aussi appelee signature ou 

MAC) Oi de 1' instruction. De plus, le X|lLP 
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acciomule le hachage du programme dans la valeur 
h au moyen de la fonction de compression Hi- 

• Dans la sous 6tape (~l-d)^ le MAC o± est envoye 

par le X|XP au XT. 

5 • Enfin^ dans la sous 6tape (-l.e), le MAC Oi regu 

du X|XP est stocke par le XT. 
Se d6roulent par la suite les 6tapes ayant lieu 
pendant I'' execution du programme P. 

A l'6tape (0)^ le X|LiP v6rifie que la valeur finale de 
10 h. calcul6e durant la boucle de l'6tape (-1) est 6gale k la 
1' identif iant ID^ stock6 dans sa memoire non volatile- 
GrS.ce ^ la propri6t6 de non-collision de la fonction de 

hachage, le X(XP est ainsi certain que le programme pour 

lequel il a calculi la s6q[uence des MACs Oi pendant les 
15 6tapes negatives est ef f ectivement autoris6 k 1*^ execution. 
De pluS/- pendant l'§tape (0), le compteur de programme i 
est initialise ^1. Si la valeur de h diffdre de celle de 
ID, le programme envoy6 n' est pas authentique, et la 

section (8) est ex6cut6e : le XfiP prend alors les mesures 

20 adequates centre 1' agression suppos6e (par exemple, le X^P 
efface sa memoire) - 

Les etapes (1), (2), (3), (4), (5), (6), (7) sont 
alors r6p6t6es un certain nombre de fois, jusqu'^ ce que 
I'' instruction finale soit ex6cut6e. Ce proc6d6 de boucle 

25 est expliqu6 dans ce qui suit. 

En 6tape (1), le X[lP initialise la variable V k IV2. 

En 6tape (2), le XT initialise la variable ok IV2. 

A l^etape (3), le X(IP demande au XT 1' instruction 
d'adresse i. 

30 A I'etape (4), le XT remet k jour la variable a et 

envoie au XfxP 1' instruction demand6e. 
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A l'6tape (5), le X\lF remet d jour la variable V, 
L'etape (6) est I'etape critique pour la s6curit6, 
Celle ci commence d'^abord par un test. 

• Si 1' instruction regue INSi est dans 1' ensemble 
5 des instructions critiques pour la s6curit§ 

les sous-etapes (6. a), (6-b) et (6.c) sont 
effectu6es. La sous-6tape (6. a) est une sous- 

6tape durant laquelle le XjxP demande au XT de 

lui envoyer la signature collective a. Le X|LiP 

10 effectue alors la comparaison avec la valeur v 

qia'il a calcul6e auparavant. Si ces valeur s sont 
diff6rentes, le programme P regu est un 
programme non-authentique et l'6tape (8) est 

alors executee : le XjxP prend alors les mesures 
15 ad6quates centre cette agression (par exemple, 

le X|XP r6-initialise sa m6moire) . Si ces valeurs 

sont 6gales, le X|J,P continue 1' execution du 
protocole en executant 1' instruction regue et en 
retournant a I'^etape (1) - 

20 • Si 1' instruction regue INS± n'est pas dans 

1' ensemble des instructions criticjues pour la 

s6curit6 S^ l'6tape (7) est ex6cut6e le X|xP 
execute simplement INSi et continue d' ex6cuter 
le proc6d6 en retournant k l'6tape (3) . 

25 

Ainsi,^ dans les 6tapes negatives, le X|LIP signe lui- 
mSme le programme qui lui est envoy6 (encore une fois avec 
une cl6 feph6m6re) ^ tout en v6rifiant que celui ci est 
authentique en comparant le hachage du prograirune qui lui 
30 est envoy6 cl 1' identif iant de programme qu'il contient dans 
sa memoire (ID) . Dans les etapes positives^ le proced6 
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permet de verifier collect ivementi- aux moments opportuns 
(c'^est ^ dire pour toutes les instructions critiques pour 
la s6curit6^ r§pertoriees dans 1' ensemble S) , cjue les 
signatures fournies par le XT sont identiques A celles que 

5 le XjxP avait calculi dans les 6tapes negatives - 

A I'instar du premier mode de rfealisation^ il est 
impossible pour le XT d'envoyer au XfxP une instruction 
6trang6re au programme: il n'a pu faire signer ^ l'6tape (- 
1) un programme different de celui d'identifiant ID sans 
10 dtre d6tect6 ^ l'§tape (0)^ du fait de la propri6t6 de non- 
collision de la fonction de hachage. En cons6quencer durant 
1^ execution des 6tapes positives, le XT ne peut qu'envoyer 

des instructions sign6es par le X|XP au cours de 1*^ execution 
des 6tapes negatives, c'est k dire les instructions 

15 correspondant ef fectivement au programme; dans le cas 
contraire, si le XT essaie d'envoyer des instructions 
diffferentes, il ne pourra envoyer la signature correcte 
lors de la verification car il ne peut calculer par lui- 
m§me les signatures d' autres instructions du fait cju' il ne 

20 connalt pas la cl6 de signature K. 

II est cependant encore possible d'am61iorer les 
performances de 1' invention k I'aide d''un troisidme mode de 
realisation de 1^ invention. 

Dans ce troisidme mode de realisation de 1' invention, 

25 un jnlveau de sScurit^ est associ6 k chacune des donnees 

manipul6es par le XjiP. II permet de distinguer une donnSe 
secrete (par exemple une cl6 cryptographique stock6e en 
m6moire non volatile) d'une donn6e publicjue (connue ou 
pouvant etre recalcuiee partir de donnees connues) . Par 

30 concision, nous denotons par 4> 1' ensemble des niveaux de 
securite definis a un instant donne par 1' execution d'un 
programme donn6. II existe plusieurs fagon de definir un 
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niveau de s6curite sur une donn§e de calculi mais I'on 
peut supposer en toute g6neralit6 que 1' ensemble <f> des 
niveaux de s6curite est initialise ^ certaines valeurs 
sp6cifiques avant 1' execution du prograirane P, et que le 

5 fait d'executer une instruction de P peut modifier <I> selon 

des rdgles arbitrairement choisies par le concepteur du 
dispositif • 

A titre d' example illustratif non limitatif^ nous 
dfecrivons ci-apr6s une r6alisation particulidre de ce 
10 proc6d6 appliqu6 k 1^ architecture XJVML d6finie plus haut, 

Le niveau de s6curit6 est mis en oeuvre sous la forme 

d'^un bit d' information cp selon la convention que sa valeur 
vaut z6ro lorsque la donn6e concern6e est publique et un 
lorsque celle-ci est secrete . Plus sp6cif iquement, la mise 
15 en oeuvre du proced6 concerne les cellules m6moires 
volatiles (RAM), non volatiles (NVM) et les cellules de 

pile (ST). Ainsir on denote par (p(R2\M[j]) le bit de 

s6curit6 associ6 au mot m6moire RAM[j], par <p(NVM[j]) le 

bit de s6curit6 associe a NVM[j] et par <p(ST[j]) le bit de 
20 s6curit6 associ6 k ST[j]. Par convention, les bits de 
s6curit6 des cellules NVM sont non volatiles et positionn6s 

^ 0 ou 1 par le fcibricant du X^iP a l'6tape de production ou 
de personnalisation, suivant la nature des donn6es non 
volatiles correspondantes . Ceux de la m^moire RAM sont 
25 initialis6es i 0 lors du reset du dispositif. Par 

convention, (p(IO) est laiss6 constant ^ 0 et cp(RNG) est 
laiss6 constant ^ 1. Enfin, les bits de s6curit6 des 
616ments de pile d6saffect6s sont automatiquement remis A 
0. 

30 Nous pr6sentons aussi deux regies 616raentaires par 

lesquelles le bit de security d'une nouvelle variable de 
prograime, c'' est-^-dire d'une donn6e issue d'un calcul oi 
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partir de donn6es pr6c6dentes/ est 6tabli en fonction de 
celui desdites donn6es prec6dentes . 

La premidre r^gle est qpae toutes les instructions de 
transfert { Uoad' ^ ^getstaticS ^store' et '^put static ' ) 
5 trans fdrent 6galeinent le bit de s6curit6 de la variable 
transferee. La seconde r^gle est appliquee aux instructions 
arithm6tiques et logiques. Elle d6finit chaque bit de 
s6curit6 des variables de sortie de 1' instruction concern6e 
coirane le OU logique des bits de s6curite de toutes les 

10 variables d'entr6e de 1' instruction, Autrement dit, 
aussitdt qu'une donn6e secrete entre dans le calcul, toutes 
les donn6es qui en d6coulent sont r6pertori6es comme 6tant 
secretes- Cette r^gle peut notamment mais non uniquement 
etre facilement cabl6e en hardware comme un simple OU 

15 boolean ("OR", denote V dans la Figure 5) pour les 
instructions binaires (c'est a dire avec deux arguments 
d'entr6e) . Par souci de clart6, nous fournissons dans la 
Figxire 5 la s6mantic[ue dynamique des instructions de XJVML 

sur 4>. 

20 Etant donn6 maintenant un jeu d' instruction 

quelconque/ et les regies permettant de d6finir au cours du 
temps 1' ensemble des niveaux de s6curit6 <J> des donn6es 
utilis6es par 1' execution d'^un programme, nous y associons 
le proc6d6 de 1' invention tel que d6crit par son second 

25 mode de realisation. Le principe du troisi^me mode de 
realisation repose sur le fait que la verification 
collective des instructions 6mises par le XT, jusqu'alors 
d6clench6e par la detection d'une instruction critique pour 
la s6curite, peut §tre 6pargnee d^s lors que cette 

30 instruction n' utilise par exemple que des donnees 
repertoriees comme publiques. Une verification de MAC n'est 
ef f ectivement pas necessairement invoquee dans ce cas 
puisque le danger inherent ^ 1' execution d' une instruction 
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critique se trouve annule par le fait qpae celle-ci ne peut 
fournir des informations cpae sur des donn6es prealablement 
connues ou modifier de telles donn6es . 

Par concision^ on denote par Alert (INS^^) la 
5 fonction bool^enne (c' est-A-dire retournant VRAI ou FAUX) 
qui determine si 1' execution de 1' instruction critique INS 
occasionne ou non une verification lorsque le niveau de 
s6curite des donn6es d'entr6e que cette instruction 

manipule est donn6 par O. 

10 Dans notre exemple de mise en oeuvre dans le cadre du 

langage XJViyiL, la fonction Alert peut Stre d^finie de 
plusieurs manidres differentes ainsi qu'illustr6 sur les 
Figures 3 et 4. 

Ainsif nous d6finissons un troisi^me mode de 

15 realisation de 1' invention^ caract6ris6 en ce qpie la sous- 
phase de verification dans la phase d' execution est une 

verification de la signature a se deroulant avant 
1' execution de 1' instruction si celle-ci est une 
instruction criticjue pour la securite, et si I'une au moins 
20 des donnees utilisees par cette instruction est une donnee 
secrete - 

De f a^on plus precise, dans ce troisidme mode, ce 
precede de s6curisation d'un objet portable eiectronique 

est caracterise en ce qu' il utilise une variable O 
25 d6finissant 1' ensemble des niveaux de securite definis k un 
instant donn6 par 1' execution d'un programme donne P et en 
ce que la phase d' execution comporte les sous-phases 
suivantes : 

b-1) le X|iP demande une instruction au XT; 
30 b-2) si cette instruction est critique pour la 

securite et si I'une au moins des donnees utilisees 
par 1' instruction est secrete, alors le Xp.P demande 
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une signature a construite ^ partir des signatures a, 

g6n6r6es lors de la phase d' initialisation et d 
I'aide de la fonction HASH2/ et^ en cas de non- 

validit6 de cette signature o, execute la phase de 
5 reaction; 

b-3) le XpP execute 1' instruction, met ^ jour le 
niveau de s6curit6 (donn6e secrdte ou donn6e non 
secrete) de chacune des donnSes issues de 
1' execution, et retourne cL la sous-phase b-1. 

10 

Decline avec 1' utilisation de la fonction bool§enne 
Alert, ce troisi^me mode de realisation est caract6ris^ en 

ce cju' il utilise une variable * d6finissant 1' ensemble des 
niveaux de s6curit6 d6finis i un instant donn§ par 
15 l^ex6cution d'un programme donn6 P, et en ce que la phase 
d' execution comporte les sous-phases suivantes : 
b-1) le XpP demande une instruction au XT; 
b-2) si cette instruction est critique pour la 
s6curit6 et si la fonction bool6enne Alert determin6e 
20 ^ partir du niveau de s6curit6 des donn^es utilis6es 

par 1' instruction et par la nature de 1' instruction 

elle-m^me s' lvalue en VRAI, alors le XjiP demande une 
signature o construite a partir des signatures 

g6n6r6es lors de la phase d' initialisation et k 
25 I'aide de la fonction HASH2r et, en cas de non- 

validit6 de cette signature a, execute la phase de 
reaction; 

b-3) le XjiP execute 1' instruction, met a jour le 
niveau de securite (donn6e secrdte ou donn6e non 
30 secrete) de chacune des donnees issues de 

1' execution, et retourne cl la sous-phase b-1. 
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De fagon pr6f6rentielle/ ce troisidme mode de 
realisation est caract6ris6 en ce qu' il utilise un ensemble 
d' instructions critiques pour la sfecuritfe S et en ce quB le 
5 protocole comprend les 6tapes suivantes: 

-2 . Le X|XP g^n^re une cl6 al6atoire de session K, demande au 
XT 1' identifiant ID du programme, le nombre d' instructions 
F qu' il contient et initialise h ^ /f^ 

-1, Pour i^l ^ F 
10 (a) Le X|XP demande au XT 1' instruction num^ro i 

(b) Le XT envoie 1' instruction INS, au XfiP 

(c) Le XfxP calcule la signature ^ |lj^ (ID5/5INS,) et 
met ^ jour h<r- H^{h^INS^) 

(d) Le X[XP envoie au XT (aucune copie de n'^est 

« 

15 gard6e dans le Xj^P ) 

(e) Le XT enregistre 

0 • Le X|i,P v6rif ie que A = ID , que ID est pr6sent en m^moire 
non volatile (en cas d'^chec aller k l'6tape 8) et 
initialise / <— 1 

20 1. Le X|llP initialise V ^-iFj 

2- Le XT initialise a /l^ 

3. Le XflP demande au XT 1' instruction num^ro i 

4. Le XT 

(a) met ^ jour a <— /TjCOja,) 

25 (b) envoie INS^ au X|llP 

5. Le X^P met k jour V ^ H^fy ^\Jig^{ID^i^INS{)) 

6- Si INSfSS et Alert (i3VS^,4>)=VRAi, le X|lP 

(a) demande 0 au XT et v^rifie que O - V ; en cas 
d'^chec/ aller k I'^tape 8 

30 (b) execute INS, 

(c) met ^ jour 4> 
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(d) retourne ^ l'6tape 1 

7. Sinon, le X\lP 

(a) execute INS^ 

(b) met k jour 4> 

(c) retourne h I'^tape 3 

8. Le X^P salt que le programme fournl est un prograiame non 
authentlquef et prend done toutes les mesures n^cessaires 
defensives de protection. 

Ainsif par difference avec le protocole d6crit dans 
le second mode de realisation de 1' invention^ une 
verification de la signature collective ct l'6tape 6 n'est 
effectuee que lorsque la fonction Alert s'6value en VRAI 
juste avant que 1' instruction critique soit execut6e. 

En fonction de la itiise en ceuvre de ladite fonction, 
le concepteur de 1' architecture obtient ainsi un moyen de 
verifier le programme en fonction du contexte, c'est-4-dire 
en evitant dans le protocole le d6clenchement d'une 
verification consideree comme inutile au regard du niveau 
de s6curit6 des donn6es en jeu. 

Dans une deuxidme partie de 1' invention, le programme 
est authentifie par groupe d' instructions, et non plus par 
instructions simples. Les instructions peuvent en effet 
etre regroupees sous la forme de petits blocs appeies 
sections qui permettent de limiter le nombre de signatures 

generees et verif i6es par le X|J,P . 

Suivant la definition classique des documents 
« Advanced Compiler Design and Implementation », de S. 
Muchnick, publi6 en 1997 et « Compilers: Principles, 
Techniques, and Tools », de A. Aho, R- Sethi et J. Ullman, 
publie en 1986, nous appelons « bloc de base » une suite 
s6quentielle et ordonn6e d'' instructions, que I'on ne peut 
ex6cuter qu' en executant la premiere et la dernidre 
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instruction. L'^hoirane de m6tier decrit habituellement 
1' ensemble des blocs de base d'un programme P sous la 
forme d'un graphe CFG(P) (CFG signifiant « control flow 
graph » en anglais) , calculfe par des moyens connus 
5 d' analyse de flot de contrSle (expliqu6s notamment dans les 
documents « Identifying Loops in Almost Linear Time », de 
G. Ramalingam/ publie en 19991- et « Advanced Compiler 
Design and Implementation »f de S. Muchnick, publi6 en 
1997) . Dans un tel graphe, les noeuds sont identifi6s aux 

10 blocs de base et les aretes symbolisent les d^pendances de 
flot de contr51e {« control flow dependancies »)• . 

La presence d'une arSte Bo -> Bi dans le graphe (on 
dit alors que Bi est un fils de Bo et Bo un pere de Bi) 
signifie que la derni^re instruction du bloc Bo peut 

15 transferer le controle du programme 4 la premiere 
instruction de Bi . 

Lorscjue Bo -> Bi, Bo => Bi signifie que Bo n'a aucun 
autre fils que Bi (mais Bi peut avoir d'autres pdres que 
Bo) - Nous d6finissons maintenant une notion l^gdrement 

20 diff6rente de celle des blocs de base^ que nous appelons 
section de programme, 

De raani^re rigoureuse, une section de programme est 
une suite maximale de blocs de base B© => Bi => B2 => ... => Bz 
telle cjue ni 1^ instruction de fin de programme (^half en 

25 XJVML) ni aucune instruction de S (instruction critique) 
n'apparaisse dans les blocs sauf 6ventuellement comme 
derniere instruction de Bz* La section est alors d6not6e 
par s = <Bo,Bi,„.^ Bz>. Dans une section de programme, comme 
dans les blocs de base, le flot de contrdle est 

30 d6terministe,^ c'est a dire ind6pendant de la valeur que les 
variables de programme sont susceptibles de prendre pendant 
1' execution . 
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II est connu que le calcul des blocs de base d'un 
prograirane peut §tre fait dans un temps presque linfeaire en 
le nombre d' instruction de ce prograirane (« Identifying 
Loops in Almost Linear Time », de G. Ramalingam^ public en 
5 1999) et I'homme de I'art verra facilement que les 
algorithmes permettant de calculer CFG(P) 4 partir de P 
peuvent §tre modifies de fagon simple pour calculer,- de 
manidre 6galement performante, 1'' ensemble des sections du 
programme P. Ainsi, les sections de P peuvent §tre 

10 calculSes facilement lors la compilation de P. 

La deuxieme partie de 1' invention se decline en un 
quatridme, cinquidme et sixiSme modes de realisation de 
1' invention cjue nous dfecrivons maintenant. Dans ces modes ^ 
les signatures sym6triques g6n6r6es par le X^P 

15 authentif lent des sections plut6t q[ue des instructions 
individuelles du programme. 

Au contraire des trois premiers modes de realisation 
de la premiere partie de 1' invention^ dans lesqpaels le 
programme 6tait fourni sous forme de suite d' instructions^ 

20 ces quatri^me, cinquidme et sixi^me modes de realisation de 
1' invention sont des procedfes de s6curisation d'un objet 
portable eiectroniqfue caracteris^s en ce que le programme P 
est fourni sous la forme d'une suite de sections ou blocs 
d' instructions, G d6notant le nombre de sections de ce 

25 programme P, et en ce qu'il utilise une troisidme fonction 
de hachage, noiran6e HASH3, definie par une fonction de 
compression H3 et une constante IV3. 

Dans cette seconde partie de 1*^ invention, la valeur de 
ID, c[ui correspond au hachage du programme P, se calcule en 

30 hachant, une k une, les sections, dans I'ordre croissant 
des adresses de ces sections, puis finalement en hachant 
les haches des sections dans I'^ordre croissant des adresses 
de depart des sections. 
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De faQon plus pr6cise^ la deuxidme partie de 
1^ invention est caracteris6e en ce que ledit protocole 
comporte les phases suivantes : 

a) une phase d' initialisation durant laquelle le XfiP 

gen^re une cl6 6ph6nidre puis regoit du XT 
1' ensemble du programme son nombre de sections G 

et son identifiant ID, calcule le hach6 h de ce 

programme P ^ I'aide de la fonction HASHi, en 

utilisant la fonction de compression Hi et la 

constante IVi, et ^ l''aide de la fonction HASH3, en 

utilisant la fonction de compression H3 et la 

constante IVa^ et enf in g6n6re des signatures o j k 

I'aide de la fonction p,K et de la cl6 signatures 
<5 J qu'il transmet au XT; 

b) une phase d' execution durant laquelle le XjiP 
verifie l'6galit6 entre les valeurs de h et de ID, 
v6rifie egalement que ID est stocke dans sa mfemoire 
non volatile, puis demande, I'une apr6s 1' autre, les 
sections de P pour les ex6cuter, effectue ensuite 
une sous-phase de verification de conformity de ces 
sections, puis finalement, pour 1' instruction finale 
de certaines sections, effectue une sous-phase de 
verification qui consiste cL demander une 

signature a, construite k partir des signatures o^ 

gen6r6es lors de la phase d' initialisation et k 
l^aide de la fonction HASH2, et ^ la verifier; 

c) une phase de reaction q[ui se d6roule dds qu'une 

signature a est non valable ou qu'une section est 
non conforme, et q[ui consiste pour le X[jP a prendre 
les mesures necessaires centre le XT frauduleux. 
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Plus precis6ment,r la sous-phase de verification de 
conforniite d'une section donnee consiste k verifier 
qu'aucune instruction de cette section, sauf 6ventuellenient 
la derni^re, n'est une instruction critique pour la 
5 s6curit6 . 

Cette deuxieme partie de 1' invention se decline alors 
en plusieurs modes / appel6s cjuatri^me, cinqui^me et sixi^me 
mode de realisation de 1' invention. 

Le quatri^me mode de realisation se caract6rise en ce 
10 que la sous-phase de verification dans la phase d' execution 

est une verification de la signature a se deroulant avant 
1' execution de 1^ instruction finale de chaque section. 

De fagon plus precise , ce quatri^me mode de 
realisation est caracterise en ce que la phase d' execution 
15 comporte les sous-phases suivantes : 

b-1) le XpP demande une section au XT; 

b-2) pour chaque instruction non finale de la section 

demandee, le XjjP verifie si cette instruction est 

critique, effectuant dans ce cas la phase de 
20 reaction, et sinon execute cette instruction et passe 

^ 1' instruction suivante; 

b-3) pour 1' instruction finale de la section 
demande e : 

b-31) le XjjP demande une signature o construite 

25 partir des signatures Gj generees lors de la phase 

d' initialisation et ^ I'aide de la fonction HASHa, 

et, en cas de non-validit6 de cette signature o, 
execute la phase de reaction; 

b-32) le XjiiP execute 1' instruction; 

30 b-4) le XjaP retourne alors k la sous-phase b-1. 
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De fagon pr6f 6rentielle, le quatrieme mode de 
realisation de 1' invention est caract6ris6 en ce qu'il 
utilise un protocole 4 cl6 secrete comprenant les 6tapes 
suivantes : 

-2. Le X^^P g^n^re une cl^ al4atoire de session K, demande au 
XT I'identifiant ID du programme, le nombre de sections 
G qu'il contient et initialise h^—IV^ 

-1. Pour j^l ii G 

(a) Le XjLlP demande au XT la sec1:ion numSro j, le nombre 
t d' instructions dans cette section et initialise 



gard^e dans le XjLlP ) 
(e) Le XT enregistre Gj 

0 . Le X|XP v^rif ie que A = ID , que ID est present en mSmoire 
non volatile (en cas d'6chec aller ^ l'4tape 9) et 



1. Le X|lP initialise V <- /Fj 

2. Le XT initialise O <— /fj 

3. Le XjLlP demande au XT la section num6ro j, le nombre t 
d' instructions qui la compose et initialise g ^ IV^ 

et i^l 

4. Le XT met jour O ^-i^aC^s^y) ®^ initialise i<— 1 

5- Le XT envoie INS^ au X|XP et incr6mente l<— i + 1 

6- Le X|LiP met a jour g <r' H^ig^INS^) 
7. Si i<t, alors le X|XP 



(c) 



(d) 



(b) 




initialise 7<— 1 
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(a) teste si INSfSS, et dans ce cas, aller k I'^tape 9 

(b) execute INS, 

<c) retourne ^ I'^tape 5 
8. Si i=tf alors le X|XP 

5 (a) met ^ jour V ir-H^fy.liA^^J^g)) 

(b) demande <J au XT et v6rifie c[ue G=V; en cas 
d'6chec, aller d l'6tape 9 

(c) execute INS, 

(d) retourne d I'Stape 1 

10 9. Le X|LLP salt que le programme fourni est un programme non 

authentiquef et prend done toutes les mesures n^cessaires 
defensives de protection. 



Dans le pr6c6dent paragraphe, et dans la suite {pour 
15 les clnqpildmes et sixidme mode de realisation) , la 
signature d'une section Sj dont la premiere instruction a 
pour adresse j et constitute des instructions INSi^ ...^ INSjc 
peut ^tre d6finie ^ titre d' exemple par : 



20 ay= ^i{lDr J, g) oii g d6signe g = HASH3 (INSi, ...^ INSk) 

HASH3 6tant ici une fonction de hachage d§finie par 
une fonction de compression H3 et un vecteur 
d' initialisation IV3 conformement k l'6tat de I'art. Le 

25 fait d' employer la definition classiq[ue du hachage par 
iteration est indispensable cL notre quatrieme^ cinqui6me et 
sixieme mode de realisation. 

Le quatri^me mode de realisation se compose lui aussi 
d'etapes negatives et positives. Nous expliquons bridvement 

30 son fonctionnementf celui ci 6tant tr6s proche des premiers 
modes de realisation. Dans l^etape (-2) ^ une cie aieatoire 
K est generee^ 1' identif iant ID et le nombre de sections G 
sont demande s . Puis h est initialise k IVi. Dans l^etape (- 
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1)^ le prograiiunae P est signe a I'aide de la cl6 K et de la 
fonction de MAC |llk. Ici^ les signatures sont des 
signatures par section. Les signatures Oj sont g6n6r6es par 
le XjxP et envoy6es ensuite au XT,, qui les stocke. Dans 
5 1^6tape (0), le X|LlP v6rifie que le programme est correct, 

en v6rifiant que le hachfe calcul6 est identique k ID, et 
que ID est present dans sa m6moire non volatile. Les 6tapes 
(1) et (2) sont des 6tapes d' initialisation pour le XfiP et 

le XT. En 6tape (3), le X|LlP demande au XT le nombre 
10 d' instruction t de la section courante, et initialise g 4 

IV3. Le XT remet quant k lui ^ jour la variable o en 6tape 
(4) et initialise i ^ 1. En 6tape (5), 1' instruction 
courante de la section courante est envoy6e au X|xP et i 

est incr6ment6. Le X|xP remet alors cL jour g, variable qui 

15 lui sert ^ accumuler le hachage de la section courante. 
L'6tape (6) est celle de la v6rification de conformity de 
la section : le X|J.P y v6rifie que toutes les instructions 

non finales sont non critiques . II execute 6galement ces. 
instructions. L'§tape (7) est celle qui se dferoule pour 

20 1^ instruction finale de la section : le X^iP demande alors 
une signature et en v6rifie 1' authenticity . En cas de 
succdSf 1' instruction est ex6cut6e, et le proc6d6 repart de 
l'6tape 1. Enfin, ^ tout moment, si une section est non 
conforme, ou si une signature est fausse, 1^6tape (9), qui 

25 est celle de l'6tape de reaction, est ex6cut6e : le X^lP 

prend alors les mesures nfecessaires de protection. 

A la difference des modes de realisation pr6c6dentS/ 
chaq[ue section ne peut occasionner au plus qu'une 
verification de MAC. On se rappellera en effet qpi'une 
30 instruction critique pour la security ne peut se trouver 
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qu'^en tant que dernidre instruction d'une section. Par 
definition, la derni^re instruction INSjc d'une section est: 

• soit une instruction de S. Dans ce cas, son 
execution peut d6clencher ou non une 

5 verification de signature, selon la politique de 

s6curit6 Alert (INS, 

• soit 1' instruction de fin de progranune {'^halt' 
en XJVML) , qui interrompt 1' execution. 

Reprenant les id6es des deuxidme et troisifeme modes 
10 de realisation, mais appliqu6es d un prograjnme P donn6 sous 
la forme de sections, nous d6rivons les cinqui^mes et 
sixi^mes modes de realisation , de 1' invention. 

Le cinquieme mode de realisation de 1' invention est 
un precede de securisation d'^un objet portable 
15 eiectronique, du type deuxi^me partie de 1' invention (c'est 
k dire avec un programme P donn6 sous la forme de 
sections) , caract6ris6 en ce que la sous-phase de 
verification dans la phase d' execution est une verification 

de la signature a se d6roulant avant 1' execution de 
20 I'' instruction finale de chaque section, si ladite 
instruction est une instruction critique pour la securite. 

Plus precis6ment, ce cinquidme mode est caracteris6 
en ce que la phase d' execution comporte les sous-phases 
suivantes : 

25 b-1) le XjxP demande une section au XT; 

b-2) pour chaque instruction non finale de la section 
deraandee, le XpP v6rifie si cette instruction est 
critique, effectuant dans ce cas la phase de 
reaction, et sinon execute cette instruction et passe 

30 a 1' instruction suivante; 

b-3) pour 1' instruction finale de la section 
demande e : 
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b-31) si 1' instruction est criticpie pour la 
security ^ le XjuiP demande une signature O construite 

k partir des signatures Oj g6n6r6es lors de la phase 
d' initialisation et k I'aide la fonction HASHar et, 
5 en cas de non-validit§ de cette signature Of execute 

la phase de reaction; 

b-32) le XpP ex6cute 1' instruction; 

b-4) le XfiP retourne alors d la sous-phase b-1. 



10 De fa^on pr6f 6rentielle^ ce cinqui^me mode est 

caract6ris6 en ce qu'il utilise un ensemble d' instructions 
critiques pour la s6curit6 S et en ce que le protocole 
comprend les Stapes suivantes : 

-2 . Ije XjilP g^n^re une cl^ al^atoire de session K, ■ demande au 
15 XT 1' identif iant ID du prograiame, le nombre de sections 

G qfu'il contient et initialise h <r- iy[ 
-1 . Pour J 4—1 k G 

(a) Le X|XP demande au XT la section num^ro j, le nombre 
t d' instructions dans cette section et initialise 

20 g<^IV^ 

(b) Pour i<— 1 ^ tf le XT envoie 1' instruction INS^au 

XfxP qui met k jour g ^ H^(g,INSf) 
<c) Le XjlP calcule la signature O j ir- \l^(ID,j,g) de la 

section et met k jour h <r- H^(Jl,g) 
25 (cl) Le XfXP envoie <J j au XT (aucune copie de 0 y n'est 

gardSe dans le X^P ) 

(e) Le XT enregistre O j 

0 . Le X(XP v6rif ie que h = ID / que ID est present en m6moire 
non volatile (en cas d'6chec aller k I'Stape 10) et 
30 initialise / «- 1 
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1. Le X|XP initialise V ^ IV2 

2. Le XT initialise O ^ IV2 

3. Le X|LLP demande au XT la section num^ro j, le noxnbre t 
d' instructions qui la compose et initialise g <— IV^ et 

5 /<-l 

4. Le XT met ^ jour O ^ H2(p ,0 j) et initialise i 

5. Le XT envoie INS^ au XjlP et incr^mente i<— i + l 

6. Le XflP met A jour g^H^{g,EfS^) 
7- Si i<t, alors le XjiP 

10 (a) teste si INS^^S, et dans ce cas, aller ^ 1^6tape 10 

(b) execute INS, 

(c> retourne k l'6tape 5 

8 . Si i«t et INS^ e S , alors le XjxP 

(a) met k jour V <^ H^fy .lljcilDJ^g)) 

15 (b) demande O au XT et v6rifie que CT^V; en 

cas d'^chec, aller k I'Stape 10 

(c) execute INS, 

(d) retourne k I'^tape 1 

9 . Si i=t et jDVS,. € S , alors le XfiP 

20 <a) met ^ jour V <-/f2(V,|l^(iZ),y,^)) 

(b) execute INS, 

(c) retourne d I'^tape 3 

10. Le X|iiP salt que le programme foumi est un programme non 

authentique^ et prend done toutes les mesures ndcessaires 
25 defensives de protection. 



Ce cinquifeme mode de r6alisation de 1' invention est 
tres proche du quatri^me/ et nous n' allons expliqpaer ici 
que les phases diff^rentes de celui ci^ c'est dire les 
30 phases 8 et 9- Dans le quatrifeme mode de realisation, 
toutes les instructions finales des sections faisaient 
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I'objet d'une verification de signature. Ici, en 6tape 
(8)^ on teste 1' instruction finale : si elle est critique^ 
on demande une signature. Par centre^ si l*" instruction 
finale n'est pas critique, alorSf dans l'6tape (9), on 
5 execute 1' instruction sans demander de signature, et on 
continue le protocole en retournant cL l'6tape 3. 

Comme on peut le voir, I'avantage est grand : seules 
certaines instructions finales feront I'objet d^une 
verification de signature, et ainsi, le protocole sera 
10 d'autant plus rapide. 

Mais il est encore possible d'apporter une derniSre 
amelioration au protocole, faisant I'objet du sixi^me mode 
de realisation de 1' invention. 

Celui ci est un proc6de de s^curisation d'un objet 
15 portable eiectronique caract6rise en ce que la sous-phase 
de verification dans la phase d' execution est une 

verification de la signature o se deroulant avant 
1' execution de 1' instruction finale de chaque section, si 
ladite instruction est une instruction critique pour la 
20 securite, et si l^une au moins des donnees utilisees par 
cette instruction est une donnee secrdte. 

Plus precisement, le sixieme mode de realisation de 
1' invention est un precede de securisation d'un objet 
portable eiectronique caracterise en ce qu'il utilise une 

25 variable <I> definissant 1' ensemble des niveaux de securite 
definis cL un instant donne par 1' execution d'un programme 
donne et en ce que la phase d' execution comporte les sous- 
phases suivantes : 

b-1) le XjyiP demande une section au XT; 
30 b-2) pour chaque instruction non finale de la section 

demandee, le XjiP v6rifie si cette instruction est 
critique, effectuant dans ce cas la phase de 
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reaction^ et sinon execute cette instruction et passe 
^ 1' instruction suivante; 

b-3) pour • 1' instruction finale de la section 
demand^e : 

5 b-31) si 1^ instruction est critique pour la security 

et si I'une au moins des donn6es utilis6es par 

1' instruction est secrete, le XjjP demande une 

signature a construite 4 partir des signatures <5 j 

g6n6r6es lors de la phase d' initialisation et a 
10 l^aide de la fonction UKSRzr et, en cas de non- 

validite de cette signature O, execute la phase de 
reaction; 

b-32) le XpP ex6cute 1' instruction; 
b-33) le XjiP met k jour le niveau de s6curit6 

15 (donn6e secrete ou donn6e non secrete) de chacune des 

donn6es issues de 1' execution ; 

b-4) le XpP retourne alors k la sous-phase b-1. 

Une autre fagon de r6aliser le sixi^me mode de 
20 realisation de 1^ invention est d'utiliser un protocole, 

caract6rise en ce qu' il utilise une variable 4> definissant 
1" ensemble des niveaux de s6curit§ d6finis k un instant 
donn§ par 1' execution d'un programme donn6, en ce qu^il 
utilise une fonction booleenne Alert et en ce que la phase 
25 d' execution comporte les sous-phases suivantes : 

b-1) le XpP demande une instruction au XT; 
b-2) pour chacjue instruction non finale de la section 
demand6e, le XfiP verifie si cette instruction est 

critique^ effectuant dans ce cas la phase de 
30 reaction, et sinon execute cette instruction et passe 

k 1' instruction suivante; 
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b-3) pour 1' instruction finale de la section 
d.einand§e : 

b-31) si 1' instruction est critique pour la s6curit6 
et si la fonction bool6enne Alert d6terrain6e k partir 
du niveau de s6curit6 des donn6es utilis6es par 
1' instruction et par la nature de 1' instruction elle- 

meme s'6value en VRAI, le XpP demande une signature 

o construite k partir des signatures Oj g6n6r6es 

lors de la phase d' initialisation et ^ I'aide de la 
fonction HASHa^ et^ en cas de non-validit6 de cette 

signature a, ex6cute la phase de reaction; 

h-32) le XjiP execute 1' instruction/ 

b-33) le XjiP met a jour le niveau de s6curite 
(donn6e secrete ou donn6e non secrete) de chacune des 
donn6es issues de 1'' execution ; 

b-4) le X|xP retourne alors a la sous-phase b-1 - 

Ainsi^ de mani^re pr6f6rentielle^ le sixi^me mode de 
realisation de 1' invention est caract6ris6 en ce qu'il 
utilise un ensemble d' instructions critiques pour la 
s6curit6 et en ce qu'il comprend les 6tapes suivantes: 

-2. Le X|XP g^ndre une cl6 al6atolre de session K, demande au 
XT 1' identif iant ID du prograinmer le nombre de sections 

G qu'il contient et initialise h IV^ 

-1, Pour j<-l ^ G 

(a) Le XjxP demande au XT la section num^ro j, le norabre 
t d' instructions dans cette section et initialise 

(b) Pour 1<— 1 cL t, le XT envoie 1' instruction INS^au 
X|J.P qui met ^ jour g <— H^(g,INSf) 

(c) Le XjxP calcule la signature cy^ |J,^(iD,/,g) de la 
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section et met ^ jour Hy^(h,g) 

(d) Le envoxe Cj au XT (aucune copie de Gj n'est 
gard6e dans le X|XP ) 

(e) Le XT enregistre O j 

0 . Le XjxP v6rif ie que A = ID , que ID est present en m^xnoire 
non volatile (en cas d'6chec aller k l'6tape 10) et 
initialise J 

1. Le X^lP initialise V <- /K^ 

2. Le XT initialise O <- IV2 

3. Le X|XP demande au XT la section num^ro J, le nombre t 
d' instructions qui la compose et initialise g ^ IV^ et I 1 

4. Le XT met k jour 0 <— JT^^C^s^y) ®t initialise f<-l 

5. Le XT envoie INS^ au X|XP et incr6mente + l 

6. Le X|lP met k jour g ir- H^(g,INSf) 

7. Si i<t, alors le X|LlP 

(a) teste si INS^ B S , et dans ce casr aller k I'^tape 10 

(b) execute INS^ 

(c) met k jour <I> 

(d) retoume k I'^tape 5 

8. Si i=t et INS^gS et Alert (J3V!S',,<I> >»VRAI, alors le XjxP 

(a) met k jour V <- H^fy ,\l^(IDJ,gy) 

(b) demande O au XT et v6rifie que 0=V; en 
cas d'^chec, aller k I'^^tape 10 

(c) execute INS^ 

(d) met k jour ^ 

(e) retoume k l'4tape 1 

9. Si i«t et {INS^^S ou Alert (i2V!S^,4> )=FAUX) , alors le X(XP 

(a) met k jour V H^(y ,\i^{IDj,g)) 

(b) execute INS^ 

(c) met k jour ^ 
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(d) retourne A l'6tape 3 
10. Le XfiP salt que le programme fouml est un programme non 

authentique^ et prend done toutes les mesures nScessaires 
defensives de protection. 

La difference de ce dernier mode de realisation avec 
le cinqui^me mode de realisation est minime, et est 
expliquee dans ce qui suit : en etape (8) ^ on ne teste pas 
seulement si 1' instruction finale est critique pour la 
s6curit6, mais aussi si une des donn§es d'entr6e de 
1'^ instruction est secrete (ceci nous est donn6 par la 

condition Alert ( i3VS,,^> ) =VRAI) . Si ces deux conditions sont 

r^unies^ une verification de signature est enclenchee^ 
1' instruction est ensuite ex^cutee, et le protocole 
red^marre de I'^etape (1). Par centre^ dans le cas 
contraire, 1' instruction est ex6cut6e sans d6clencher de 
verification de signature^ et le protocole redemarre de 
1 ^ etape ( 3 ) . 

Comme pourra le voir I'homme de I'^art, le dernier 
protocole minimise au maximum le nombre de signatures 
demandees au XT^ tout en garantissant la securite du X|xP . 

Dans le deuxieme ou troisidme modes de la premiere 
partie de 1' invention, et dans le cjuatrieme^ cinquidme ou 
sixidme mode de la deuxieme partie de 1*^ invention^ le 
precede est caracterise en ce qpi' au moins un des types 
suivants d^ instructions sont critiques pour la securite : 

les instructions de test et/ou 

les instructions emettant de 1' information vers 
I'exterieur par un mo yen de communication et/ou 

les instructions modifiant le contenu de la 
memoire non- volatile et/ou 
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les instructions de calcul pr6sentant des cas 
particuliers lors de leur execution, tels que le 
lancement d' exceptions . 
De plus, les troisi^me et sixi^me modes sont 
pr6f6rentiellement caract6ris6s en ce que la fonction 
booleenne Alert s'evalue en VRAI pour au moins un des types 
suivants d' instructions : 

les instructions de test et/ou 

les instructions 6mettant de 1' information vers 
I'exterieur par un moyen de communication et/ou 

les instructions modifiant le contenu de la 
m6moire non-volatile et/ou 

les instructions de calcul pr6sentant des cas 
particuliers lors de leur execution, tels que le 
lancement d' exceptions . 

Dans une solution encore plus efficacef les troisiSme 
et sixi^me modes sont caract6ris6s en ce que la fonction 
bool6enne Alert s'6value en VRAI pour au moins un des types 
suivants d' instructions,^ si au moins une des donn6es 
d'entr6e est secrete, et FAUX si toutes les donn§es test^es 
sont publiques: 

les instructions de test et/ou 

les instructions 6mettant de 1' information vers 
l'ext6rieur par un moyen de communication et/ou 

les instructions modifiant le contenu de la 
m6moire non-volatile et/ou 

les instructions de calcul pr6sentant des cas 
particuliers lors de leur execution, tels que le 
lancement d' exceptions . 
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Pour les troisieme et sixiSme modes^ 1' ensemble des 
niveaux de s6curite 4> utilis6 lors de 1' execution d'un 
programme P est pr6f 6rentiellement indiqu6 par la valeur 
d'^une fonction (p^ telle que, pour toute donnee u utilis6e 
5 par le programme, <p(u)=0 d6slgne le fait que u est publique 

et <p(u)-l dfesigne le fait que u est priv6e, et telle que, 
pour toute donnee v resultant de 1' execution d^une 
instruction du programme P, <p(v)=»l si au moins une des 
donn6es d'^entrfee de 1' instruction est priv6, et, sinon, 
10 <p{v)=0. 

Plus pr6cis6ment, les valeurs de la fonction (p sont 
calculees au moyen d'une mise en oeuvre mat6rielle d'une 
fonction « OU logique » r6alis6e sur les valeurs de la 

fonction <p pour les donn^es d' entree des instructions. 
15 Enfin, par souci de simplicity et de pratique, les 

fonctions de hachage HASHi, HASH2 et HASH3 peuvent Stre 
identiques - 

La pr6sente invention s'appliqpje ^ un objet 
61ectroniqnae caracteris6 en ce qu'il met en oeuvre 
20 1' ensemble des modes de realisation de 1' invention tels q[ue 
d6crits ci-dessus. 
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1. Proced6 de s6curlsation d' instructions d'un objet 
portable electronique X|jP ex6cutant un prograinme P 
fourni par un autre objet 61ectronique non sGr XT 
5 sous la forme d'une suite de F instructions, F 

d6notant ainsi le noinbre d' instructions de ce 
programme proced6 utilisant 

- un protocole k cl6 secrete coop6rant avec une cl6 

secrete 6phem^re K; 

10 . une fonction cryptographique sym6trique MAC \Ik 

coop6rant avec une fonction de hachage HASHi,. 
definie par une fonction de compression Hi et une 
const ante IVi, et une fonction de hachage HASH2 
d6finie par une fonction de compression H2 et une 

15 constante IV2; 

- un identifiant de programme ID stock6 dans 1' objet 

61ectronique Xp.P et valant un hachage de P,^ 
proc6d6 caract6ris§ en ce que ledit protocole A cl6 
publique comporte les phases suivantes : 
20 a) une phase d' initialisation durant laquelle le 

XiiP g6n6re une cl6 6ph6m6re puis regoit du 
XT 1^ ensemble du programme Fr 1© nombre 
d'' instructions F et son identifiant ID, 
calcule le hache h de ce programme P avec la 
25 fonction HASHi, en utilisant la fonction de 

compression Hx et la constante IVi, et enfin 
gfen^re des signatures a, ^ I'' aide de la 
fonction |llk et de la cl6 K, signatures a, qu'il 
transmet au XT; 
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b) une phase d' execution durant laquelle le XjtP 
v6rifie l'6galit6 entre les valeurs de h et de 
ID, verifie- 6galement que ID est stocke dans 
sa ni6moire non volatile, puis demande, I'une 
apr^s 1' autre, les instructions de P pour les 
executer, et pour certaines d' entre elles, 
effectue une sous-phase de verification qui 
consiste k demander une signature a, construite 
k partir des signatures g6n6r6es lors de la 

phase d*^ initialisation et k I'aide de la 
fonction HASH2, et ^ verifier cette 
signature a; 

c) une phase de reaction qui se deroule dds qu'une 
signature G est non valable. 

2- Proc6d6 de s6curisation d' instructions d'un objet 
portable 61ectronique selon la revendication 1 
caract6ris6 en ce que la sous-phase de verification 
dans la phase d' execution est une verification de la 

signature o se d6roulant avant 1' execution de chaque 
instruction, 

3- Proc6d§ de securisation d' instructions d'un objet 
portable eiectronique selon la revendication 2 
caract6ris6 en ce que la phase d' execution comporte 
les sous-phases suivantes : 

b-1) le Xp-P demande une instruction au XT; 

b-2) le XpP demande une signature a construite k 
partir des signatures g6nerees lors de la 

phase d' initialisation et a 1' aide la fonction 
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HASH2/ et, en cas de non-validit6 de cette 
signature execute la phase de reaction; 
b-3) le XpP execute 1' instruction et retourne k 
la sous-phase b-1. 

4. Proc6d6 de s6curisation d' instructions d'^un objet 
portable 61ectronique selon la revendication 1 
caract6ris6 en ce que la sous-phase de verification 
dans la phase d' execution est une verification de la 

signature a se d6roulant avant 1' execution de 
1' instruction, si celle-ci est une instruction 
critique pour la s6curit6. 

5, Proc6d6 de s6curisation d' instructions d'un objet 
portable 61ectronique selon la revendication 4 
caract6ris6 en ce quB la phase d' execution comporte 
les sous-phases suivantes : 

b-1) le XpP demande une instruction au XT; 

b-2) si cette instruction est criticjue pour la 

s6curit6, alors le X^P demande une signature a 

construite a partir des signatures gen6r6es 

lors de la phase d'' initialisation et ^ I'aide la 
fonction HASH2f et, en cas de non- validity de 

cette signature a, execute la phase de reaction; 

b-3) le X}iP execute 1' instruction et retourne k 

la sous-phase b-1. 

6- Precede de securisation d'un objet portable 
6lectronique selon la revendication 1 caract6ris6 en 
ce que la sous-phase de verification dans la phase 
d' execution est une verification de la signature o 
se d6roulant avant 1' execution de 1' instruction si 
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celle-ci est une instruction critique pour la 
s6curit6^ et si I'une au moins des donn6es utilis6es 
par cette instruction est une donn6e secrdte, 

7. Proc6d6 de s6curisation d' instructions d'un objet 
portable 61ectronique selon la revendication 6 

caracteris6 en ce qu'il utilise une variable ^ 
dfefinissant 1' ensemble des niveaux de s6curit6 
d6finis 4 un instant donn6 par l'ex6cution d'un 
programme donn6 P et en ce que la phase d' execution 
comporte les sous-phases suivantes : 

b~l) le XnP demande une instruction au XT; 
b-2) si cette instruction est critique pour la 
s6curit6 et si I'une au moins des donn6es 
utilisees par 1' instruction est secrete, alors le 

XpP demande une signature a construite k partir 

des signatures 0^ g6n6r6es lors de la phase 

d'' initialisation et k I'aide la fonction HASH2, 

etf en cas de non-validit6 de cette signature Of 
execute la phase de reaction; 

b-3> le X|iP execute 1' instruction^ met 4 jour 
le niveau de s6curit6 (donnee secrete ou donn6e 
non secrete) de chacune des donnees issues de 
l'ex6cution^ et retourne k la sous-phase b-1- 

8. Proc6d6 de s6curisation d' instructions d'un objet 
portable ilectronique selon la revendication 7 

caract6ris6 en ce cju'il utilise une variable 0 
d6finissant 1' ensemble des niveaux de s6curit6 
d6finis k un instant donn6 par 1' execution d'un 
programme donn6 P, en ce qu' il utilise une fonction 
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bool6enne Alert et en ce que la phase d'' execution 

comporte les sous-phases suivantes : 

b-1) le XjiP demande une instruction au XT; 
b-2) si cette instruction est critique pour la 
s6curite et si la fonction bool6enne Alert 
d6terniin6e d. partir du niveau de s6curit6 des 
donnSes utilis6es par 1' instruction et par la 
nature de 1' instruction elle-m§me s' lvalue en 

VRAI^ alors le XpP demande une signature o 

construite ci partir des signatures a, g6ner6es 
lors de la phase d^ initialisation et ^ I'aide la 
fonction HASH2, et^ en cas de non-validit6 de 
cette signature execute la phase de reaction; 
b-3) le XjjP execute 1^ instruction^ met k jour 
le niveau de s6curit6 (donn6e secrete ou donn6e 
non secrete) de chacune des donn^es issues de 
1^ execution, et retourne A la sous-phase b-1. 

9. Proc6d6 de s6curisation d' instructions d'un objet 
portable 61ectronique selon la revendication 1^ 
caract6ris6 en ce qu'^il utilise une fonction de 
hachage HASH3 definie par une fonction de compression 
H3 et une constante IV3, et en ce que le programme P 
est fourni sous la forme d'une suite de G sections 
ou blocs d' instructions;- G d6notant ainsi le nombre 
de sections dudit programme - 

10, Precede de s6curisation d' instructions d'un objet 
portable 6lectronic[ue selon la revendication 9 
caracterise en ce que ledit protocole comporte les 
phases suivantes : 
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a) une phase initialisation durant laquelle le 

XfiP g6n6re une cle eph6m6re K, puis regoit du 

XT l*" ensemble du programme P/ son nombre de 
sections G et son identifiant ID, calcule le 
hach6 h de ce programme P k I'aide de la 
fonction HASHi, en utilisant la fonction de 
compression Hi et la constante IVi, et cL I'aide 
de la fonction HASH3, en utilisant la fonction 
de compression H3 et la constante IV3, et enfin 

g6n6re des signatures Gj d I'aide de la 
fonction |i.K et de la cl6 signatures Oj qu'il 

transmet au XT; 

b) une phase d' execution durant laquelle le XpP 

v6rifie l'6galit6 entre les valeurs de h et de 
ID, v6rifie 6galement que ID est stock6 dans 
sa m&noire non volatile, puis demande, I'une 
aprds 1' autre, les sections de P pour les 
ex6cuter, effectue ensuite une sous-phase de 
v6rification de conformity de ces sections, 
puis finalement, pour 1' instruction finale de 
certaines sections, effectue une sous-phase de 
verification qui consiste k demainder une 

signature o, construite cl partir des signatures 

gen6rees lors de la phase d' initialisation 

et k I'^aide la fonction HASH2, et ct la 
verifier; 

c) une phase de reaction qui se d^roule dSs c[u'une 

signature a est non valable ou qu'une section 
est non conforme. 

11. Proced6 de securisation d^ instructions d'un objet 
portable 61ectronique selon la revendication 10 
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caract6ris6 en ce que la sous-phase de verification 
de conformit6 d'une section donn§e consiste cL 
verifier qu'aucune instruction de cette section, 
sauf 6ventuellement la dernidre, n'est une 
5 instruction critiqpae pour la s6curit6. 

12. Proc6d6 de s6curisation d' instructions d'un objet 
portable 61ectronique selon la revendication 11 
caract6ris6 en ce que la sous-phase de verification 

10 dans la phase d^ execution est une verification de la 

signature o se dferoulant avant 1^ execution de 
1' instruction finale de chaque section. 

13. Proced6 de s6curisation d' instructions d'un objet 
15 portable 61ectronique selon la revendication 12 

caract6ris6 en ce que la phase d' execution comporte 

If 

les sous-phases suivantes : 

b-1) le XjiP deraande une section au XT; 

b-2) pour chaque instruction non finale de la 

20 section demand6e, le XpP v6rifie si cette 

instruction est critique, effectuant dans ce cas 
la phase de r6action, et sinon execute cette 
instruction et passe cL 1' instruction suivante; 
b-3) pour 1' instruction finale de la section 
25 demand6e : 

b-31) le X+iP demande une signature a 

construite A partir des signatures g6n6r6es 

lors de la phase d' initialisation et ^ l''aide 
la fonction HASH2, et, en cas de non-validit6 

30 de cette signature o, execute la phase de 

reaction; 

b-32) le XjjP ex6cute 1' instruction; 
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b-4) le XjiP retourne alors a la sous- 

phase b-1. 

14. Proc6d6 de s6curisation d' instructions d'un objet 
portal>le 61ectronique selon la revendication 11 
caract6ris6 en ce que la sous-phase de verification 
dans la phase d' execution est une verification de la 

signature a se dferoulant avant 1' execution de 
1' instruction finale de chaq[ue section, si ladite 
instruction est une instruction critique pour la 
s6curit6 - 

15. Proc6d6 de sfecurisation d' instructions d'un objet 
portable 61ectronique selon la revendication 14 
caract6ris§ en ce que la phase d' execution comporte 
les sous-phases suivantes : 

b-1) le XpP demande une section au XT; 

b-2) pour chaque instruction non finale de la 

section demandSe, le XpP v6rifie si cette 

instruction est critique, effectuant dans ce cas 
la phase de reaction, et sinon execute cette 
instruction et passe ^ 1' instruction suivante; 
b-3) pour 1' instruction finale de la section 
demand^e : 

b-31) si 1'' instruction est critique pour la 
s6curit6r le X^iP demande une signature o 

construite k partir des signatures Oj g§n6r6es 

lors de la phase d' initialisation et ^ I'aide 
la fonction HASH2, et, en cas de non-validit6 

de cette signature a, execute la phase de 
reaction; 

b-32) le XjiP execute 1' instruction/ 
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b-4) le XjiP retourne alors k la sous-phase b-^l. 

16- Proc6de de securisation d' instructions d'un objet 
portable 61ectronique . selon la revendication 11 
5 caract6ris6 en ce que la sous-phase de verification 

dans la phase d' execution est une verification de la 

signature a se deroulant avant l'ex6cution de 
1' instruction finale de chaque section, si ladite 
instruction est une instruction critique pour la 
10 s6curit6/ et si I'une au moins des donn6es utilis6es 

par cette instruction est une donn^e secrete. 

17. Proc6d6 de s6curisation d' instructions d'^un objet 
portable 61ectronique selon la revendication 16 

15 caract6ris6 en ce qu'il utilise une variable <J 

d6finissant 1' ensemble des niveaux de s6curit6 
d6finis un instant donnS par 1' execution d'un 

programme donn6 et en ce que la phase d' execution 
comporte les sous-phases suivantes : 
20 b-1) le XpP demande une section au XT; 

b-2) pour chaque instruction non finale de la 
section demandee, le XpP v6rifie si cette 

instruction est critique, effectuant dans ce cas 
la phase de reaction, et sinon execute cette 
25 instruction et passe ol 1' instruction suivante; 

b-3) pour 1*^ instruction finale de la section 
demand^e : 

b-31) si 1' instruction est critique pour la 
s6curit6 et si I'une au moins des donn^es 
30 utilis6es par 1*^ instruction est secrete, le 

XpP demande une signature a construite cL 
partir des signatures a, g6n6r6es lors de la 
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phase initialisation et ^ I'aide la 

fonction HASH2, et^ en cas de non-validit6 de 

cette signature a, execute la phase de 

reaction; 

5 b-32) le XpP execute I'' instruction; 

b-33) le XpP met ^ jour le niveau de 

s6curit6 (donn§e secrete ou donn6e non 
secrete) de chacune des donn6es issues de 
1^ execution ; 

10 b-4) le X^P retourne alors a la sous-phase b-1. 

18. Proc6d6 de s6curisation d' instructions d'un objet 
portable 61ectronique selon la revendication 16 

caract6ris6 en ce qu'il utilise une variable 3> 
15 d6finissant 1' ensemble des niveaux de s6curit6 

d6finis k un instant donn6 par 1' execution d'un 
programme donnS, en ce qu'il utilise une fonction 
boolfeenne Alert et en ce que la phase d' ex6cution 
comporte les sous-phases suivantes : 
20 b-1) le XpP demande une instruction au XT; 

b-2) pour chaque instruction non finale de la 
section demand^e^ le XpP v6rifie si cette 
instruction est critic[ue, effectuant dans ce cas 
la phase de r6action^ et sinon execute cette 
25 instruction et passe ct 1' instruction suivante; 

b-3) pour 1' instruction finale de la section 
demandSe : 

b-'31) si 1' instruction est critique pour la 
s6curit6 et si la fonction bool6enne Alert 
30 determinee a partir du niveau de s6curit6 des 

donnSes utilis6es par 1' instruction et par la 
nature de 1' instruction elle-mSme s'6value en 
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VRAI^ le XjjP demande une signature a 

construite A partir des signatures Gj g6n6r6es 

lors de la phase d' initialisation et k I'aide 
la f one t ion HASHar etf en cas de non-validit6 

de cette signature G, execute la phase de 
rfeaction; 

b-32) le Xm-P execute 1' instruction; 

b-33) le XpP met A jour le niveau de 

security (donn6e secrete ou donn6e non 
secrete) de chacune des donnSes issues de 
I'' execution ; 

b-4) le XjiP retourne alors A la sous-phase b-1. 

19. Proced6 de s6curisation d'' instructions d'un objet 
portable 61ectronique selon I'une quelconqpae des 
revendications 4^8 ou 11 k 18, caract6ris6 en ce 
qu'au moins un des types suivants d' instructions 
sont critiques pour la s6curit6 : 

les instructions de test et/ou 

les instructions 6mettant de 1' information vers 
l'ext6rieur par un moyen de communication et/ou 

les instructions modifiant le contenu de la 
m6moire non-volatile et/ou 

- les instructions de calcul pr6sentant des cas 
particuliers lors de leur ex6cution^ tels que le 
lancement d' exceptions . 

20. Proced6 de securisation d*^ instructions d' un objet 
portable 61ectronique selon I'une quelconque des 
revendications 8 ou 18, caract6ris6 en ce que la 
fonction bool6enne Alert s'6value en VRAI pour au 
moins un des types suivants d' instructions : 
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les instructions de test et/ou 

les instructions 6inettant de 1' inf oinnation vers 
I'exterieur par un moyen de communication et/ou 

les instructions modifiant le contenu de la 
5 m6moire non-volatile et/ou 

les instructions de calcul pr6sentant des cas 
particuliers lors de leur execution^ tels c[ue le 
lancement d' exceptions . 

10 21. Proc6d6 de s6curisation d' instructions d'un objet 

portable 61ectronique selon I'une quelconque des 
revendications 8 ou 18, caract6ris§ en ce cjue la 
fonction bool^enne Alert s'^fevalue en VRAI pour au 
moins un des types suivants d'^ instructions, si au 

15 moins une des donn6es d' entree est secrete, et FAUX 

si toutes les donnees test6es sont publiques: 

les instructions de test et/ou 

les instructions 6mettant de 1'' information vers 
l'ext6rieur par un moyen de communication et/ou 

20 - les instructions modifiant le contenu de la 

m6moire non-volatile et/ou 

les instructions de calcul pr&sentant des cas 
particuliers lors de leur execution, tels c[ue le 
lancement d' exceptions . 

25 

22. Proc6d6 de securisation d' instructions d'un objet 
portable 61ectroniqfue selon I'une qpaelconque des 
revendications 1 k 8 ou 17 ^ 18, caract6ris6 en ce 

que 1' ensemble des niveaux de s6curit6 O utilisfe 
30 lors de 1' execution d'un programme P est indiqu§ par 
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la valeur d'une fonction <p^ telle que, pour toute 

donnSe u utilises par le programme, <p(u)=»0 d6signe 

le fait que u est publique et <p(u)=»l d6signe le fait 
que u est priv6e, et telle qiae, pour toute donnSe v 
5 resultant de 1' execution d'^une instruction du 

programme P, <p(v)=l si au moins une des donn&es 
d'entr6e de 1' instruction est priv6e, et sinon 

<p(v)=0. 

23. Proc6d6 de s6curisation d' instructions d'un objet 
portable 61ectronique selon la revendication 22, 

caract6ris6 en ce que les valeurs de la fonction <p 
sont calcul6es au moyen d'une mise en oeuvre 
mat^rielle d'une fonction « OU logique » r6alis6e 

sur les valeurs de la fonction (p pour les donn6es 
d'entr6e des instructions - 

24. Proc6d6 de s6curisation d' instructions d'un objet 
portable Slectronicjue selon I'une c[uelconque des 

20 revendications 1 4 23, caract6ris§ en ce cjue les 

fonctions de hachage HASHi, HASH2 et HASH3 sont 
identiques • 

25. Objet 61ectronique caract6ris6 en ce qu'il met en 
25 oeuvre I'une quelconqfue des revendications 1 ^ 24. 
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